[% setvar title Extensions to the perl debugger %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Extensions to the perl debugger</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: David Storrs &lt;<a href='mailto:dstorrs@dstorrs.com'>dstorrs@dstorrs.com</a>&gt;
  Date: 25 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: <a href='mailto:perl6-language@perl.org'>perl6-language@perl.org</a>
  Number: 292
  Version: 2
  Status: Frozen</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>The perl debugger is good, but there are several features it lacks (or at
least, that it lacks convenient, single-key commands for) that would be
extremely useful.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>The following features appear in many modern IDEs, but not in the perl
debugger.   It is generally possible to duplicate this functionality by
writing an appropriate command string, but there should be easy ways to do
these things.</p>
<ul>
<li><a name='1'></a>1</li>
<p>The ability to easily retrieve and edit your N most recent commands to the
debugger (much like a bash_history).</p>
<li><a name='2'></a>2</li>
<p>A better default pager.  The default pager should assume a 24x80 term
window and use an absolute minimal number of control characters (e.g., use
spaces in preference to horizontal tab) to format things.  This is not
particularly fast or efficient but people who want that can reset it to
something else, and using an absolute minimal one will make life easier
for people (like me!) who use limited telnet clients to get to the box
which runs Perl for them.</p>
<li><a name='3'></a>3</li>
<p>The ability to look at an object and, with just one or two keystrokes,
list</p>
<ul>
<li><a name='(A)'></a>(A)</li>
<p>the names of all its ancestors,</p>
<li><a name='(B)'></a>(B)</li>
<p>the names of all its descendants,</p>
<li><a name='(C)'></a>(C)</li>
<p>the names of everything in its inheritance hierarchy (i.e., all of its
ancestors, itself, all of its descendants).</p>
</ul>
<p>Note that it is possible (generally by error) to construct cyclic
inheritance graphs; the debugger would need to detect this and cope with
it.</p>
<li><a name='4'></a>4</li>
<p>The ability to provide a function name (preferably just the first unique
section of its name) and</p>
<ul>
<li><a name='(A)'></a>(A)</li>
<p>jump to where that function is defined,</p>
<li><a name='(B)'></a>(B)</li>
<p>list the names of all functions that call that function,</p>
<li><a name='(C)'></a>(C)</li>
<p>show all lines in the current package or file which call that function,</p>
<li><a name='(D)'></a>(D)</li>
<p>show all lines in the program (including linked modules) which call that
function,</p>
<li><a name='(E)'></a>(E)</li>
<p>list all user-defined functions that that function calls
=back</p>
<li><a name='5'></a>5</li>
<p>The debugger should be better at storing state.  I should be able to do
this:</p>
<pre>        &lt;DB1&gt; $foo = 2
        &lt;DB2&gt; p $foo</pre>
<p>and have it print &quot;2&quot;</p>
<li><a name='6'></a>6</li>
<p>It should be possible to enter multiline commands into the debugger
without having to backslash each new line.  This could be done by using
prefix and postfix command strings as markers (perhaps ML: and :LM) to
show where the multiline begins and ends, or by simply making the engine
smarter (difficult, I know).</p>
<li><a name='7'></a>7</li>
<p>The O command should be extended to allow user modification of what is
printed when the debugger must display an undef value (e.g., O
undef_str=**UNDEF**).  If the default value is &quot;&quot;, then we will maintain
backwards compatibility.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>1) The history functionality only requires a buffer in which to store the
most recent N strings.</p>
<p>2) The pager should be relatively straightforward; it is intended to be
extremely minimalist, after all.</p>
<p>3) Showing the ancestors of an object is easy (just dump @ISA), but
showing the descendants might be harder, since it requires scanning the
@ISAs of all known objects (unless there is some magic from -internals?).
The best might be to construct a giant @ISA graph of all classes at
runtime.  Note the possibility of circular inheritance graphs, and the
fact that @ISA can be modified at runtime, which would require modifying
the graph.</p>
<p>4) The function tracking will be difficult, and will require much help
from the -internals people.</p>
<p>5) I'm not sure how to handle this one.  I'm tempted to say that the
debugger should simply store its state in the program's stash, but that
might cause problems.  It will mean that the debugger cannot simply &quot;eval&quot;
all commands and then forget them.</p>
<p>6) See RFC 184 for discussion on this.</p>
<p>7) This should be straightforward, I hope.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>perldebug man page</p>
<p>RFC 184: Perl should support an interactive mode.</p>
</div>
